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FOREWORD 


The Software Engineering Laboratory (SEL) is an organization 
sponsored by the National Aeronautic^ and Space Administra- 
tion Goddard Space Flight Center (NASA/GSFC) and created for 
the purpose of investigating the effectiveness of software 
engineering technologies when applied to the development of 
applications software. The SEL was created in 1977 and has 
three primary organizational members; 

. NASA/GSFC (Systems Development and Analysis Branch) 

The University of Maryland (Computer Sciences Department) 
Computer Sciences Corporation (Flight Systems Operation) 

The goals of the SEL are (1) to understand the software de- 
velopment process in the GSFC environment; (2) to measure 
the effect of various methodologies/ tools / and models on 
this process; and (3) to identify and then to apply success- 
ful development practices. The activities, findings, and 
recommendations of .the SEL are recorded in the Software En- 
gineering Laboratory Series, a continuing series of reports 
that includes this document. A version of this document was 

, i 

also issued as Computer Sciences Corporation document 
CSC/TM- 81/60 91 . 

Contributors to this document include 

William J. Decker (Computer Sciences Corporation) 

Frank McGarry (Goddard Space Flight Center) 

Single copies of this document can be obtained by writing to 

Frank E. McGarry 
Code 582.1 
NASA/GSFC 

Greenbelt, Maryland 20771 


ABSTRACT 


This report summarizes the experiences of the Goddard Space 
Flight Center (GSFC) Code 580 Software Engineering Laboratory 
(SEL) with the components of a programmer workbench. Phase I 
of the SEL programmer workbench consists of the design of the 
following three components: communications link, command 

language processor, and collection of software aids. A brief 
description, an evaluation, and recommendations are presented 
in this document for each of these three components. 
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SECTION 1 - INTRODUCTION 


This report summarizes the experiences of the Goddard Space 
Flight Center (GSFC) Code 580 Software Engineering Laboratory 
(SEL) with some of the components of a programmer workbench. 
Programmer workbench is a term which Code 580 personnel apply 
to an integrated set of software aids made available in a 
uniform manner on an interactive computer system. Probably 
the best-known example of a programmer workbench is the Bell 
Telephone Laboratories' PWB/UNIX (Reference 1). 

The SEL programmer workbench is similar in several respects 
to PWB/UNIX; however, because what was needed was an aid to 
the development process of the flight-dynamics-type software 
typical of the Code 580 environment, differences evolved. 
Specifically, in order for any feature to be included in the 
SEL programmer workbench, it had to be effective in the de- 
velopment of high-quality flight dynamics software. 

The SEL programmer workbench design, as developed by a pre- 
vious task assignment, specifies the following five major 
components : 

r 

• A high-speed communications link between the SEL 
development computer (a Digital Equipment Corporation 
(DEC) PDP-11/70) and the application computer (the 
Mission and Data Operations (M&DQ) IBM S/360-95) 

• A shared supervisor task on the PDP-11/70 which man- 
ages the task of each individual session and queues 
all transmissions on the communications link 

« A command language processor to provide the interface 
between the user and the session task 

• A file librarian system to map the command language 
file specifications into the actual PDP-11/70 or IBM 
S/360-95 file designations and to control the use of 
public shared-access libraries 
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• A collection of software aids useful to flight 
dynamics software development 

The designs of three of these five components have been re- 
fined enough to be evaluated at this time. These three are 
(1) the communications link, (2) the command language proc- 
essor, and (3) the software aids. The evaluations given in 
this document attempt to describe the strengths and weaknesses 
of each and, where possible, indicate new directions that 
might be taken when further refining of the design is complete. 

Sections 2, 3, and 4 present a brief description, an evalu- 
ation, and recommendations for the communications link, 
software aids, and command language processor, respectively. 
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SECTION 2 - COMMUNICATIONS LINK 


2.1 INTRODUCTION 

The communications link is the component of the SEL program- 
mer workbench that enables users on the development computer 
(a PDP-11/70) to submit jobs to be processed on the applica- 
tions computer (an IBM S/360-95) . The separation of the 
development and applications areas has the advantage of re- 
ducing the scheduling and priority allocation conflicts that 
arise when these areas must share resources. However, total 
isolation of these &reas is not practical, especially in the 
later stages of software development when tests must be per- 
formed on the applications machine and error correction per- 
formed on the development machine. The communications link 
provides an efficient alternative to shifting the entire 
development effort to the applications machine. 


2.2 COMMUNICATIONS LINK DESCRIPTION 

The communications link enables users of the PDP-11/70 to 
submit jobs to the IBM S/360-95 and to receive output from 
the completed jobs. The link hardware consists of a DQ11 
Synchronous Serial Interface and a dedicated 9600 baud line.* 
The link software (the RJE Program) emulates an IBM 3780 
Remote Job Entry (RJE) terminal. 

The RJE Program was written for the PDF RSX-11D operating 
system by GSPC Code 934. The program was converted to the 
RSX-11M operating system for Code 580 by Systex, Incorporated 
and became operational within the SEL in June 1980. Since 
that time, the program has seen some limited by steady use. 


2.3 EFFECTIVENESS AND USE 

In one sense, this type of communications link can be con- 
sidered to be a one-way link; i.a., the PDP-11/70 users can 
task the IBM S/35Q-95, while the S/360-95 users cannot task 
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the PDP-11/70 . However, this is not a limitation upon the * 
intended purpose of the PDP-360 link, because there are few 
times when an applications environment generates tasks for 
the development effort. In other words, software "flows" 
from the development area to the applications area, and this 
fact is reflected in the RJE link capabilities. A more com- 
plex communications setup is therefore not required. 

One telling observation can be made at this time. After almost 
1 year of availability to Code S80 development projects, the 
communications link has not been demonstrated to be critically 
needed. If it were not available, no current or planned proj- 
ect would be stopped or seriously delayed. All projects using 
the RJE Program have alternate (although slower and less con- 
venient) methods of submitting jobs to the IBM S/360-95. 

The reasons for the lack of a critical role for the communica- 
tions link in the Code 580 development efforts are not readily 
apnarent. Since the RJE Program is easy to use and functions 
reliably, user dissatisfaction does not seem to be the cause. 

A more likely reason is the relative newness of the idea. 
Project planners may be unaware of the RJE capability or un- 
familiar with the ways in which it can be used to facilitate 
the development-area-to-applications-area transition. 

2 . 4 CONCLUSIONS AND RECOMMENDATIONS 

To date, the RJE communications link has fulfilled its purpose 
in demonstrating the feasibility of a connection between the 
PDP-11/70 and the IBM S/360-95. The RJE Program has also 
shown that communications between a development machine and 
an applications machine can be effective when only the devel- 
opment machine can generate tasks . The importance of this 
second finding lies in the fact that if a more complex com- 
munications link is not required, a limit is placed upon the 
complexity (and, hence, the cost) of the link software. 
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It is recommended that some effort be made to include the 
use of the RJE Program in the preliminary plans for a sel- 
ected SEL project so that it can be fully integrated into 
the complete software development process from <*he start. 
Thus, the full impact of the carefully planned use of the 
RJE link capability could be assessed. 

No changes are contemplated to the RJE Program at the pres- 
ent time. This is due primarily to the current simplicity 
and ease of use of the RJE capability. Another considera- 
tion, however, is the uncertainty surrounding the details of 
the components and structure of a proposed new Flight Dynam- 
ics System computing facility. The design of the new system 
could possibly eliminate the need for a separate communica- 
tions link for the programmer workbench through the incor- 
poration of multipurpose links. 
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SECTION 3 - SOFTWARE AIDS 


3 . 1 INTRODUCTION 

The concept of the programmer workbench calls for an inte- 
grated set of software aids which can be applied to the . 

Code 5&0 software development process. The term "software 
aid" as used here includes development tools and utilities 
from any source. For example, many basic software aids are 
usually supplied by the computer vendor along with the hard- 
ware. These aids include file manipulation utilities and 
compilers for the major high-order languages. Other more 
complex but still general-purpose aids, such as data base 
management systems or word processing software, are available 
from independent software vendors. 

However, experience in the SEL indicates that the greatest 
success has been achieved with tools or utilities developed 
in-house to satisfy applications specific to the Code 580 
environment . 

3.2 GSFC CODE 580 ENVIRONMENT 

The Code 580 computing environment can be described in terms 
of the size and the type of software development projects and 
the application areas served by the development. 

Code 580 software development results in software systems 
that range in size from 5,000 to 120,000 lines of code. A 
typical (average) system has 40,000 lines. When possible, 
a high-order language (typically FORTRAN) is used. The de- 
velopment is carried out primarily in an interactive environ- 
ment on both PDP-11/70 and IBM S/360 computers. 

The software can be characterized as scientific application 
systems with little or no real-time or near-real-time require- 
ments. Attitude determination and control systems require 
software to access large data bases and to perform flight 
dynamics analysis. Orbit determination and control systems 
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require celestial mechanics software that is mainly mathe- 
matical and algorithmic. Spacecraft maneuver planning re- 
quires mathematical and algorithmic software that models a 
particular vehicle's physical and dynamic characteristics. 
Mission planning software is the generalized maneuver plan- 
ning software that is used to evaluate vehicle performance 

while the total mission is still in its definition phase. 

* * 

3.3 CRITERIA FOR SOFTWARE AIDS 

The following two lessons have been learned about what makes 
a utility or tool useful to SEL users: 

• A software aid is more effective when it is simple. 

• The set of software aids must be an integrated set. 

3.3.1 SIMPLICITY 

Experience within the SEL tends to indicate that a simple 
tool r vi" utility achieves wide and long lasting acceptance 
more often than a complex tool or utility. Simplicity here 
means that each aid should have a single purpose, with a 
small number of options. The options should provide flex- 
ibility of function for the aid but should not add unrelated 
capabilities to it. 

The interaction with the user is thus limited to prompting 
for information needed to perform one function. If the user 
makes an error, it is more likely to be detected as an error 
because it cannot be interpreted as a request for an alter- 
nate function. 

3.3.2 INTEGRATED SET 

An integrated set of software aids is achieved when the aids 
are invoked with a common syntax and when the range of capa- 
bilities is adequate to allow the user to perform all required 
actions. A uniform syntax is important to the user, since it 
results in a shorter learning period and a lower error rate 
after the syntax is learned. 
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Section 4 of this document describes a proposed syntax and 
list of commands. These commands are representative of cur- 
rent capabilities within the SEL, but they do not represent 
the only possible list. 

The selection of software aids for inclusion in the program- 
mer workbench will continue until well after the introduction 
of the workbench into the SEL environment. 

3 . 4 CONCLUSIONS 

In conclusion, the following can be said about software aids 
for the SEL programmer workbench: 

• The tools and utilities to be selected should perform 
a single function. 

• The common command syntax implied by the programmer 
workbench concept will in itself be an aid to users. 

• The list of software aids included in the program- 
mer workbench is expected to evolve with time. 
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SECTION 4 - COMMAND LANGUAGE PROCESSOR 


4 . J. INTRODUCTION 

The command language processor is the component of the pro- 
grammer workbench that ties together all components into a 
useful whole. The processor interprets the user's typed 
commands and invokes the particular component of the work- 
bench required to perform the requested function. 

The effectiveness of the programmer workbench concept will 
depend heavily on the user's acceptance of the system, and 
a well-structured, easy-to-learn-and-use language will con- 
tribute to user satisfaction. 

The following subsections describe the proposed command 
language, recommend some additions to the language, and 
present some arguments in support of continued in-house de- 
velopment of the command language processor (as opposed to 
the use of software from other workbench projects) . 

4.2 SEL COMMAND LANGUAGE DESCRIPTION 

The syntax and lexicon of the SEL, as developed in the previ- 
ous task assingment, are given in Figure 4-1 and Table 4-1, 
respectively. The language is structured to take advantage 
of the processor-defined defaults whenever possible. For 
example, if the user enters 

EDIT MODULE 

the command language processor will assume that the file 
MODULESRC .FPP is to be edited, since the default type of file 
content is source code (SRC) and the default language is 
structured FORTRAN (FPP) . Of course, the user can override 
these defaults if desired, but the defaults have been chosen 
to minimize this need in the Code 580 environment. 
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Figure 4-1. Command Language Syntax (1 of 2) 
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NOTATION 

UPPER CASE 
LOWER CASE 
SQUARE BRACKETS 
PARENTHESES 
VERTICAL BA'RS 

Figure 4-1. 



NOTATION KEY 


MEANING 

REQUIRED 5PELLING 

USER-SUPPLIED INFORMATION 

[ ] OPTIONAL INPUT 

C ) OPTIONS WITHIN AN OPTION 

I ONE OF SEVERAL IS TO BE’ 

SELECTED 


Command Language Syntax (2 of 2) 
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Table 4-1. 


Command Language Lexicon (1 of 3) 




Command 


Description 


BASELINE 

BACKUP 

CALCULATE 

CALL 

CHANGE 

COMPILE 

COMPARE 

CONTROL 

COPY 

CREATE 

DATE 

DEBUG 

DELETE 

DIRECT 

EDIT 


Produce & baseline tree chart with the specified 
file as the root, extending for a specified num- 
ber of levels 

Copy the working (or other specified) library to 
a packed file 

Enter calculator mode, evaluate an expression 

Use (or create or modify) a command list to exe- 
cute a module, performing necessary compiling 
and task building 

Global edit function to change (and list) all 
occurrences of specified string in a file or a 
library (see FIND) 

Precompile, compile module (optionally, on tar- 
get system) 

Compare two files, list differences, optionally 
produce SLP editor script 

Generate command list (as used by CALL or 
SUBMIT) 

Produce copy of the file with new generic name, 
version = 1 

Call EDI to create new text file (defaults to 

SRC.FPP, but also used for GESS, test 

files, documentation, and others) 

Display current date in selected format (also 
used as a format converter; e.g., calendar day 
to Julian day) 

Specify debug mode for execution of module (see 
CALL) 

Mark generic name (or specific subfile) for 
deletion 

Produce directory listing of working (or other 
specified) library, with various formatting/ 
processing options 

Call EDI to edit file (see CREATE) ; may also 
perform copy function prior to editing (see 
COPY) 
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Table 4-1. Command Language Lexicon (2 of 3) 


Command 


Description 


EXECUTE 

EXIT 

FIND 

GESS 

GESSDOC 

HELP 

INSTALL 

LINK 

LIST 

LOAD 

PFILE 

PRINT 

REGEN 

RENAME 

RESTORE 

RETRIEVE 

RUNOFF 

SCAN 


Task build and execute module, compiling if 
necessary; unlike CALL, does not use command 
list 

End session, delete files marked by DELETE, 
optionally restart session 

Global search function to list all occurrences 
of specified string in module or library (see 
CHANGE) 

Process GESS source, optionally on target sys- . 
tern (similar to COMPILE) 

Extract system description data from GESS 
source files 

Print description, format, defaults of speci- 
fied command 

Copy specified module source into controlled 
library 

Create task (compile if necessary) from module 

List specified file on terminal (see PRINT) 

Use (or create or modify) command list to com- 
pile module and install the SRC. OBJ file 

into the object library < 

Display (or specify) the primary default module 
name 

Print specified file on printer (see LIST) 

Regenerate specified intermediate version of 
controlled source from original source and SLP 
editor script 

Rename specified generic module file or subfile 

Copy working (or other specified) library from 
backup packed file (see BACKUP) 

Retrieve target system output data sets to 
programmer workbench 

Call text processor for format module onto 
output device/file 

Call fast-look editor to examine listings, 
output files 


Table 4-1. Command Language Lexicon (3 of 3) 


Command 


Description 


SDOC Extract prologue and program design language 

(PDL) from module source files and from depend- 
ent modules, as required (see BASELINE) 

SIZE List size characteristics of module or subfile 


STATUS 

SUBMIT 

SYNCH 

TEST 

TIME 

TRACE 

TRANSMIT 

UPDATE 

XREF 


Return status of specified job on target system 

Queue command list and files for submission to 
target system 

Produce SLP script to convert one file into 
second file (see COMPARE) 

Specify test mode for execution of module (see 
CALL) ; use temporary version of module (cf . 
PANVALET) 

Display current time in optionally specified 
format; also used as format converter (see 
DATE) 

Specify trace mode for execution of module 
(see CALL) 

Use (or create or modify) command list to move 
files between the programmer workbench and tar- 
get system 

Use SLP script to update controlled source ' 
(see SYNCH) 

Create specified type of cross reference from 
module or from working (or specified) library 


A further extension of the default definition idea is to 
extend the concept to the module name itself. For example, 
if the user enters 

EDIT MODULE 
COMPILE 

the compiler selected will be the structured FORTRAN compiler 
and the input to the compiler will be the file MODULESRC .FPP . 

The use of defaults is quite common in interactive command 
languages and results from a desire to reduce the number of 
user keystrokes and, therefore, the chance for error. Another 
consideration is the relative speed with which a command is 
typed, compared with the machine response time and the user's 
thought processes. The command language processor answers 
this problem with multiprocess commands such as CALL 
(COMPILE + LINK) and LOAD (COMPILE + INSTALL). In this way, 
common sequences are collected into one command. 

4.3 USEFUL FEATURES ABSENT FROM THE COMMAND LANGUAGE 
PROCESSOR DESIGN 

Although much thought was given to command ease of use, the 
following two features which should be included in the com- 
mand language processor design were omitted: 

• Stored command sequence file processor 

• Last-command-recall capability 

The stored command sequence processor is a utility that reads 
a specified file containing command language statements and 
executes them as if they were entered by the user. Such a 
processor is available in almost all command languages with 
various levels of sophistication. This feature enables users 
to control quite complex and often unique processes with an 
absolute minimum of keystrokes . 

With the last-command-recall feature, the user can recover 
the last typed command for modification and/or resubmission. 
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A series of commands containing only small differences can 
thus be executed quickly. The primary benefit occurs when 
the user can recall a command after a syntax error is de- 
tected. In this case, the user need only correct the part 
of the command containing the error before continuing. 

4.4 IN-HOUSE DEVELOPMENT CONSIDERATIONS 

The choice of developing a command language processor in-house 
for the SEL programmer workbench (rather than using software 
from other workbench projects) has the advantage of close 
control of the language capabilities, which is necessary in 
a research environment. 

In-house development allows the addition of a monitoring fea- 
ture to the processor. This monitor can extract information 
about the commands that are. processed (e.g., command use fre- 
quency, error rates, or execution success/failure) . These 
statistics can be used by management to monitor progress in 
a particular software development project. 

The statistics can also be used by programmer workbench devel- 
opers to evaluate the system's effectiveness and performance. 
Commonly used command sequences can be detected and incorpor- 
ated into the language as new commands, and frequently used 
com. .nds can be streamlined into a simpler syntax. Language 
elements which are not used or are determined to not be ef- 
fective in developing flight dynamics software may even be 
removed from the language, thus reducing the confusion that 
a cluttered language can cause. 


4 . 5 RECOMMENDATIONS 


Further work needs to be done on the command language proc- 
essor design. In particular, work should be concentrated in 
the following areas: 

• More detailed design of the default definition rules, 
especially in the transition from single-module com- 
mands (EDIT, COMPILE) to multimodule commands (LINK, 
EXECUTE) 

• Establishing priorities for a staged implementation 
of the processor 

e A continuing review of the particular commands to be 
included 
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